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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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1. Introduction 


Electronic Data Interchange (EDI) provides a means of conducting 
structured transactions between trading partners. The delivery 
mechanism for these types of transactions in a paper world has been 
the postal system, so it is to be expected that electronic mail would 
serve as a natural delivery mechanism for electronic transactions. 
This specification permits formatted electronic business interchanges 


to be encapsulated within MIME messages [Bore92]. For the 
specification effort, the basic building block from EDI is an 
interchange. 


This specification pertains only to the encapsulation of EDI objects 
within the MIME environment. It intends no changes in those objects 
from the primary specifications that define the syntax and semantics 
of them. EDI transactions take place through a variety of carriage 
and exchange mechanisms. This specification adds to that repertoire, 
by permitting convenient carriage through Internet email. 
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Since there are many different EDI specifications, the current 
document defines three distinct categories as three different MIME 
content-types. One is Application/EDI-X12, indicating that the 
contents conform to the range of specifications developed through the 
X12 standards organization [X125, X126, X12V]. Another is 
Application/EDIFACT, indicating that the contents conform to the 
range of specifications developed by the United Nations Working Party 
4 Group of Experts 1 EDIFACT boards [FACT, FACV]. The last category 
covers all other specifications; it is Application/EDI-consent. 


2: APPLICATION/EDIFACT SPECIFICATION 


The Application/EDIFACT MIME body-part contains data as specified for 
electronic data interchange by [FACT, FACV]. 


Within EDIFACT, information is specified by: 


MIME type name: Application 

MIME subtype name: EDIFACT 

Required parameters: none 

Optional parameters: CHARSET, as defined for MIME 
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 


transfer encoding 


Security considerations: See separate section in the 
document. 

Published specification: Contained in the following section. 

Rationale: The EDIFACT specifications are 


accepted standards for a class of 
inter-organization transactions; 
this permits their transmission 
over the Internet, via email. 


Contact-info: See Contact section, below. 
Detail specific to MIME-based usage: 
This is a generic mechanism for sending any EDIFACT 
interchange. The object is self-defining, in terms of 
indicating which specific EDI objects are included. Most 


EDI data is textual, but special characters such as some 
delimiters may be non-printable ASCII or some data may be 
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pure binary. For EDI objects containing such data, the MIME 
transfer mechanism may need to encode the object in Content- 
Transfer-Encoding: quoted-printable or base6é4. 

Bie APPLICATION/EDI-X12 SPECIFICATION 


The Application/EDI-X12 MIME body-part contains data as specified for 
electronic data interchange by [X125, X12.6, EDIV]. 


Within MIME, EDI-X12 information is specified by: 


MIME type name: Application 

MIME subtype name: EDI-X12 

Required parameters: none 

Optional parameters: CHARSET, as defined for MIME 
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 


transfer encoding 


Security considerations: See separate section in the 
document. 

Published specification: Contained in the following section. 

Rationale: The ASC X12 EDI specifications are 


accepted standards for a class of 
inter-organization transactions; 
this permits their transmission 
over the Internet, via email. 


Contact-info: See Contact section, below. 
Detail specific to MIME-based usage: 


This is a generic mechanism for sending any ASC X12 
interchange. The object is self-defining, in terms of 
indicating which specific EDI objects are included. Most 
EDI data is textual, but special characters such as some 
delimiters may be non-printable ASCII or some data may be 
pure binary. For EDI objects containing such data, the MIME 
transfer mechanism may need to encode the object in Content- 
Transfer-Encoding: quoted-printable or base6é4. 
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4. APPLICATION/EDI-CONSENT SPECIFICATION 


The Application/EDI-consent MIME body-part contains data as specified 
for electronic data interchange with the consent of explicit, 
bilateral trading partner agreement exchanging the EDI-consent 
traffic. As such, use of EDI-consent only provides a standard 
mechanism for "wrapping" the EDI objects but does not specify any of 
the details about those objects. 


Within MIME, EDI-consent information is specified by: 


MIME type name: Application 

MIME subtype name: EDI-consent 

Required parameters: none 

Optional parameters: CHARSET, as defined for MIME 
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 


transfer encoding 


Security considerations: See separate section in the 
document. 

Published specification: Contained in the following section. 

Rationale: Existing practice for exchanging 


EDI includes a very wide range of 
specifications which are not part 
of the usual, accredited standards 
world. Nevertheless, this traffic 
is substantial and well- 
established. This content type 
provides a means of delimiting such 
content in a standard fashion. 


Contact-info: See Contact section, below. 
Detail specific to MIME-based usage: 


This is a generic mechanism for sending any EDI object 
explicitly agreed to by the trading partners. X12 and 
EDIFACT object must be sent using their assigned MIME 
content type. EDI-consent is for all other EDI objects, but 
only according to trading partner agreements between the 
originator and the recipient. Most EDI data is textual, 
but special characters such as some delimiters may be non- 
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printable ASCII or some data may be pure binary. For EDI 
objects containing such data, the MIME transfer mechanism 
may need to encode the object in Content-—Transfer- 
Encoding: quoted-printable or baseé4. 


5. SAMPLE EDI USAGE IN MIME-BASED EMAIL 


Actual use of EDI within MIME-based mechanisms requires attention to 
considerable detail. This section is intended as an example of the 
gist of the formatting required to encapsulate EDI objects within 
Internet mail, using MIME. To send a single EDIFACT interchange: 


To: <<recipient organization EDI email address>> 
Subject: 

From: <<sending organization EDI email address>> 
Date: 


Mime-Version: 1.0 
Content-Type: Application/EDIFACT 
Content-Transfer-Encoding: QUOTED-PRINTABLE 


<<standard EDIFACT Interchange goes here>> 
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7. SECURITY CONSIDERATIONS 


EDI transactions typically include sensitive data, so that 
transmission often needs to attend to authentication, data integrity, 
privacy, access control and non-repudiation concerns. This 
specification permits transmission of such sensitive data via 
Internet mail and other services which support MIME object 
encapsulation. For transmission of sensitive data, it is essential 
that appropriate security services, such as authentication, privacy 
and/or non-repudiation be provided. 


This specification does NOT, itself, provide any security-related 
mechanisms. As needed and appropriate, such mechanisms MUST be 
added, either via Internet MIME-based security services or any other 
services which are appropriate to the user requirements, such as 
those provided by EDI-based standards. 
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10. 


APPENDIX - MIME FOR EDI USERS 


To assist those familiar with EDI but not with Internet electronic 
mail, this Appendix is provided as a very brief introduction, 
primarily to give pointers to the relevant specifications. This 
section is in no way intended to be a thorough introduction. An 
excellent introductory text is [Rose93]. 


Internet electronic mail follows the classic user agent/mail transfer 
agent model. In this model, user software produces a standardized 
object which is transferred via standard exchange protocols. 


An Internet electronic mail object comprises a collection of headers, 
followed by a (possibly structured) body. The headers specify such 
information as author and recipient addresses, subject summary, 
creation date, handling node names, and so on, and are defined by 
RFC822 and RFC1123 [Croc82, Brad89]. If the body is structured, it 
conforms to the rules of the Multipurpose Internet Message Exchange 
(MIME) [Bore92]. A structured body may have parts encoded in 
different text character sets, or even of entirely different types of 
data, such as voice or graphics. 


The Simple Mail Transfer Protocol (SMTP) [Post82, Brad89] performs 

the primary task of message transmission. User posting and delivery 
interactions, between the user agent and the message transfer agent, 
on the same machine, are not standardized and are platform-specific. 


An EDI-related use of Internet Mime email will have (at least) the 
following components: 


Business Program/Data base -> EDI Translator -> 
-> MIME encapsulation -> RFC822 packaging -> mail 
submission -> 

-> SMTP relaying -> 

-> mail delivery -> RFC822 & Mime stripping -> 

-> EDI Translator -> Business processing 


The first and last lines show components normal to all EDI activities, 
so that it is only the EDI "transmission" components that are replaced 
with Internet modules. 
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